2 Biggest Documentation Issues MSPs Struggle with 2024

Published 2 months ago5 min readAI Advantages for MSPs...

Documentation management and how MSPs commonly fail in this arena will be the topic of today’s article. If you are anything like me then you know that the topic of MSP documentation gives me a mild chubby.

**I apologize profusely, over 2,000 words and I am only two points in of the 30 points promised and it is a hassle to change the url name and do the redirects etc so please ignore the url name of this page.

I just love the way in which if you set up help desk documentation in a structured way then with a reasonable amount of staff training, you can get the satisfaction not felt since putting together a meccano set as a child.

We all have to make a living and so take on jobs that do not always give us that deep sense of achievement. The jobs that fall into this category for me are when our team is engaged to manage one specific component in an MSP documentation project. So for example putting in a password naming convention or implementing a document naming structure.

While you are here, Take a look at some of our other Computer Consulting related articles below that may interest you:

I may get a little bump of satisfaction at the end but it is nothing like the feeling of having a client come to us knowing their documentation framework has grown “organically” as in zero planning since 1998 and now they have reached a size where they understand that the lack of planning and organization is holding them back if not, making them go backwards.

When they are over 15 technical staff, have been using a documentation framework app like IT Glue for at least 6 months and have never assigned a single dedicated resource to manage a IT documentation project then the only thing I hear is “I want you to draw me like one of your French girls”

A blank canvas with a willing client, an understanding that things are going to get worse before they get better and of course the ability to afford the project from start to end, what is not to like?

I find the best way to learn is to read about what does not work as well as examples of people doing things wrong so that I can ensure I do not make the same mistake. So with that in mind, I am going to list a couple of really important examples of common mistakes MSPs make with their documentation both their clients and their internal documentation.

“Would an idiot do that? And if they would, I do not do that thing” Dwight Schrute

Not Billing Clients For Documentation

Not billing clients for documentation is the biggest problem I see and one that has the greatest impact on service providers. Stop shoe horning client documentation between “proper billable work”

No, it does not matter if it is part of a project or your own technical team has highlighted a deficiency in a client's documentation, you need to be invoicing for it.

Are you Mother Teresa? Do you want to roam from one town to another dressed in sheets? No, you are here to make money, it is not a shameful practice and yet so many service providers tend to have this belief that our clients are our best friends and because they were so benevolent as to sign on to your monthly service agreement then anything else should be classed as a freebee.

You should be keeping metrics on time it takes to complete help desk tickets and regularly review repeat tickets and analyze them to ensure there is adequate documentation to ensure that your help desk completes it in an effective time frame.

Now if there is not a document exists for that client that is required and it is not a simple generic document you can copy from your templates then you should either have an agreed to monthly budget where the client allows you to invoice for extras up to a pre agreed amount without approval, a prepaid block of hours for incidentals like documentation or you need to contact them and obtain approval.

What I see so often is the following thought process which is one of the deadly sins of being an MSP “Damn this problem keeps coming up and it's taking 3 times longer than it should because it is not documented. Well, creating the document will save our support desk time and make it more efficient so I suppose we should just absorb that cost”

This becomes habit forming and before you know it, you are handing out freebies like it's going out of fashion. This does two things, it reduces your MSP profitability and secondly it reduces your support desks capacity to do paid work.

Both ends of the stick. If the help desk was not creating documentation for free then they would have more time to undertake work clients are paying for. By doing freebies, you cause pressure on your support staff which leads to low staff morale, increased staff turn over and before you know it you are downing a bottle of vodka before lunch and checking yourself into rehab, it is not healthy for either yourself or your clients.

A simple rule of thumb is the following questions that you need to ask yourself in the table below. If the answers match up to the table below then you absolutely should bill for the work. There would be a sliding scale between a strong yes and a weak yes if some of the answers are different from what is below.

Invoicing Rule Decision	Situation Exists Or Not
Is creating this document of benefit to this client?	YES
Does the signed agreement specify this work as included?	NO
Did you advise the client that documentation labor is included?	NO
Could you use the document if the client left tommorow?	NO
Will completing this document reduce labor cost?	YES
Does the client expect you to knowingly provide sub par service?	YES

Now there are only two outcomes here, either the client is going to agree to you invoicing for the time it will take to create a document on their behalf or they are going to say no.

This may appear like a very small example of capitulation if they say no and you do the work for them anyway “because it saves you time in the long run” Ever seen one of those big oil tankers where they have a tiny little crack in the steel structure of the ship?

Before the captain has actually registered there is a small stress fracture, whoof, the front half of the ship has detached and is already sinking to the bottom while the crew is hoping the helicopter gets there in time.

This is exactly the same. This one decision is such a big factor in if you are going to become a successful MSP and is actually a really good moment to determine if the client is going to become a long term client or if you decide to terminate the relationship at the next available opportunity.

You are the expert organization. I do not care if you are a one man operation or have 200 staff, the client has hired you because they do not have the capability to maintain and manage their own IT systems. They do not have the capability of deciding what is and is not important.

So if they say yes then good work, you have established a precedent with them that documentation is a billable task outside of the main service agreement.

If they say no then my advice is to either make it clear that they are going against your recommendations and that because their decision will cost you more over time (because the documentation does not exist for the problem) then an option is to advise again in writing as well as verbally, that if this specific problem arises again then you will have no choice but to invoice separately outside of the agreement.

Now of course if you are making a killing with this particular client in other areas, say you are making a 50% profit margin on a large scale cloud backup solution or they spend big on regular project work then you need to pick your battles and perhaps you can absorb some documentation tasks but there absolutely needs to be other income from that client that cushions documentation tasks while leaving an adequate profit margin.

In my experience, I got to a point where I stopped doing stuff for free and I stopped using the money I am making on one pile to justify doing free things over here on another pile.

That comes with experience and it's a bit like a game of poker. Clients will always be testing and looking for weakness, they absolutely will force you to make a decision that risks all of your chips.

If they see you flinch then they win. All I can say is that by being a little more aggressive in protecting my profitability by putting all my chips in on a decision, I personally never had a client walk away because of this that was not already halfway out the door.

No Strategy For Withholding Company Knowledge

It is so easy to have a right hand man or 10 who have been with you for a decade and know your clients and procedures like the back of their hand, they are so good they can do their job with their eyes closed and retain a level of information about your business that only years of service creates.

I am sure many of you have been here before, you know, Damo the gun firewall expert who installed pretty much every piece of networking equipment in every single one of your top 20 clients over the last 5 years has just advised that “I am moving on”.

Sure you try to hide that gulp on hearing the information and have become acutely aware of the excess perspiration being produced, hoping nobody can smell the fear on you, but your mind races to figure out exactly where all of the documentation Damo must have created over the years for all of those projects actually is.

Well it is not good worrying now because even the most generous resignation notice is not going to help if consistent documentation has not been regularly undertaken and reviewed.

It is easy for me to say that you should have had a documentation strategy in place where regular checks and evaluations were made; however, unfortunately, it is not going to help you this time.

So my tip and you can take this to the bank, before the next resignation, undertake a few simple steps so that you are never in this dreadful situation ever again.

Just think for a second when did Noah build the ark? Before the rain, before the rain....

My best advice here is if you must use your senior techs to write documentation (which I heavily recommend against) is to put in place a system where junior technicians (level 1 up to mid level experienced Level 2 or techs with between 1-6 years experience) are required to use the documentation created when resolving issues.

That sounds nice and easy but you need to be putting in place a system so that the quality of the documentation can be evaluated. Without going into details, I used to use IT Glue workflow rules combined with hooks into MS Teams where alerts would be delivered in relevant channels.

An environment where constructive criticism is encouraged and where blame is not used as a weapon is the only way this strategy can thrive. If you throw around blame then people will not record areas required for improvement and it will cause animosity. My view is if you have an ultra competitive culture where you pit staff against each other then I cannot help you.

Metrics such as time to fix, number of phone calls required, step of document where help was required to name a few. You do not want to make it too complex but make it effective enough so that poor documentation practices do not go hidden until the individual leaves the organization. Feedback on logic and ease of use from junior technicians should always be welcomed; however you should always review the reasons for criticism and ensure they are valid.

An example here is a junior tech giving a document a poor evaluation for say a guide that requires a vendor organization to always be created as an organization instead of adding the vendor's contact details in a router configuration notes area because it takes longer to do and requires more clicks. In this situation, the junior tech needs to be educated on the correct way of undertaking a particular task.

If a junior tech marks a document as poor because steps 5 to 11 are missing and the person that wrote it says “those steps are common sense so I did not put them in” then it is the person who wrote the document that needs some attitude readjustment.

The important thing with the above framework is that nothing is a surprise and once staff are trained on evaluating each other's documentation then it is like a rising tide lifts all boats type of situation and it becomes one less problem you need to deal with.

If you have left this attitude fester over time then it is time to nip it in the bud. Part of changing the culture of your organization is linked to my first point and that is charging clients for any and all documentation work.

If you do that first step, then you can legitimately advise your techs that the client is paying good money for the documentation to be completed so it needs to be completed to a high standard. By appealing to their sense of professionalism in their chosen career, you can quickly stamp out this idea that the task of documentation is an afterthought that will not be a reflection on their professionalism if it is ignored.

Here is a table of real world situations that I have experienced and believe it or not in some cases, the MSP leadership sided with the junior technician (Putting Vendor details in configuration notes exclusively)

Managers Question	Senior Techs Answer
“How come there is only a new blank ITG document called router user setup guide that is 3 months old?”	“Hehehe, yeah, you know how much I hate documentation, I will take a look but we probably do not need it anyway, it is really simple, just get the guys to give me a call if they have problems”
“I noticed a password you created in IT Glue called James password with no username, no IP address, no notes but there is a password in the password section, do you remember what it is for or who James is?”	“Listen, I do not have time for this, I am flat out, the help desk keeps calling me for pointless things they should know, they are so useless, I think it is for the new switch I put in and it is above James desk on the wall”
“I cannot find the primary contact of ACME vendor anywhere which is used for 4 of our clients, did I not ask you to record these details last week”	“Yep, I did it for one client and put it under the router configuration so it is easy to access when I am working on that router. I will have to update the other 3 clients with the identical contact details. Yes I know I could create an organization and only have to do it once then point all clients to that one record but this is more convenient for me and while I am the only person who could possibly know where these records are, it takes less clicks to get to the information.”
“How come you never associate a device with the device's password? I advised many times that a device password cannot exist without a device and yet you forget that same step every time”	“I have been in IT for 10 years and never needed to associate devices and passwords before, anyone who cannot work it out should not be in IT.”
“Have you noticed all of the duplicate contacts appearing in our documentation platform? Seems to have been happening for at least 3 months and now we sometimes have contacts in triplicate and each one of them now has service tickets and other records assigned meaning it is going to be a massive job to rectify the issue?”	“Yeah I did notice that when it started but it was all too much so I just pick one of the 3 when creating a ticket and have been using this spreadsheet of all the contacts that I have on my desktop, it's all good though because I emailed it to the rest of the help desk as well”
“How come there are 140 clients that are no longer clients syncing across to IT Glue that have 6 different company types with most being set to “needs updating” I thought I asked for you to allow only two organization types to sync which are either client or vendor so that the help desk does not have to waste time trying to find actual clients in amongst records of ex clients?	“I was going to but one of the old clients rang last month and we still need their information just in case and plus you never know, they might come back. Hehehe, you know how terrible I am at documentation especially when I have real work to do”

Conclusion

Well I had intended to do a very superficial article on 30 mistakes MSPs fail at when it comes to documentation and I am 2 points in and over 2000 words so I am going to cut it there.

You can console yourself with the knowledge that the other 28 mistakes that I promised will come in later articles. That is the problem when I get on the topic of MSP documentation, I tend to get a bit overexcited, of course given the subject matter, it is perfectly understandable.

We have a number of other IT system management and consulting articles listed below that will provide you with more detailed information on a number of related topics:

https://optimizeddocs.com/blogs/consulting/consulting-index-page-01

Our team specializes in strategies for IT implementation partners and we assist in improving profit margins through standardization and consistent record keeping strategies, so you can be confident that our content is tailored to your needs.

Please feel free to explore our other articles and click on any that interest you. If you have any questions or would like to learn more about how we can help you with your documentation needs, please click the "Get In Touch" button to the left and we will be happy to assist you. Thank you for choosing us as your trusted source for technology documentation.